Red Hat OpenShift Service on AWSがGAになったので触ってみた

Red Hat OpenShift Service on AWSがGAになったので触ってみた

AWSとRed HatがサポートするOpenShiftのマネージドサービスである、Red Hat OpenShift Service on AWS（ROSA）がGAとなりました！
#AWS
#コンテナ
#Docker
#Kubernetes
とばち

とばち

facebook logohatena logotwitter logo
Clock Icon2021.03.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

コンサル部のtobachi（@toda_kk）です。

AWSとRed Hatがサポートする、OpenShiftのマネージドサービスがGAとなりました！ サービスの正式名称は Red Hat OpenShift Service on AWS とされ、ROSAと略されるようです。

AWS環境でOpenShiftを構築する際、これまではVPCやEC2インスタンスなどAWS側のリソースを自前で構築・管理する必要がありました。今回GAとなってROSAを利用することで、AWSリソースの構築が簡易化できるようです。

これまでOpenShiftを利用したことがないので、イメージをつかむために実際に触って試してみました。

Red Hat OpenShiftとは？

Red Hat社が提供する、DockerやKubernetesをベースとするエンタープライズ向けのコンテナサービスです。

あくまでも個人の見解ではありますが、すごく雑に言えば、Kubernetesを良い感じにラップしたサービスおよびツールのようです。

ROSAを利用してみる

GAと共に公開されたAWS公式ブログの記事を参考に、実際にROSAを触ってみます。

事前準備

まずは事前準備を済ませておきます。

ROSAを有効化する

AWSマネジメントコンソールからROSAの画面を表示して "Enable OpenShift" ボタンを押下することで、ROSAを有効化できます。

また、有効化するとROSAを利用するためのCLIがインストールできるので、PATHを通しておきましょう。

Red Hatアカウントを作成する

OpenShiftはRed Hat社がSaaSとして提供するしているため、Red Hatアカウントを作成しておく必要があります。

OpenShift CLIのインストール

ROSA CLIに加えて、OpenShiftを動かすためのコマンドラインツールも必要になります。こちらもインストールしてPATHを通しておきましょう。

$ rosa version
1.0.1
$ oc version
Client Version: 4.7.3
Kubernetes Version: v1.19.3

ROSAでOpenShiftクラスターを作成してみる

事前準備ができたら、AWS公式ブログの手順に従い、AWS環境を使ってOpenShiftクラスターを作成してみます。

まず、ROSA CLIを利用して、AWS CredentialsでROSAを利用するIAMポリシーが付与されているかどうかを確認します。必要なポリシーについてはRed Hatによる公式ドキュメントをご参照ください。

ポリシーに問題なければ下記のように出力されます。

$ rosa verify permissions
I: Validating SCP policies...
I: AWS SCP policies ok

次に、ROSAにログインします。初回のログイン時は、Red Hatアカウントにアクセスするためのtokenが必要になります。出力されるURLからtokenを取得できるので、入力するとログイン完了となります。

$ rosa login
To login to your Red Hat account, get an offline access token at https://cloud.redhat.com/openshift/token/rosa
? Copy the token and paste it here: 
I: Logged in as '${Red Hatアカウントのユーザー名}' on 'https://api.openshift.com'

ログインが完了するとrosa whoamiコマンドでログイン情報を確認できます。AWSアカウントと一緒に、Red Hatアカウントに付随するOpenShift Cluster Manager（OCM）のアカウント情報が表示されます。

$ rosa whoami
AWS Account ID:               123456789012
AWS Default Region:           ap-northeast-1
AWS ARN:                      arn:aws:iam::123456789012:user/iam-user
OCM API:                      https://api.openshift.com
OCM Account ID:               XXXXXXXXXX
OCM Account Name:             XXXXX
OCM Account Username:         XXXXX
OCM Account Email:            xxx@xxx.com
OCM Organization ID:          XXXXXXXXXX
OCM Organization Name:        XXXXXXXXXX
OCM Organization External ID: XXXXXXX

ちなみに、入力したログイン情報は、コマンドラインを実行したユーザーのホームディレクトリ配下に作成されるocm.jsonファイルに記載されます。未検証ですが、別のRed Hatアカウントでログインしたい場合はこのファイルを書き換えれば良さそうです。

ログインが完了したら、rosa initコマンドを実行してクラスター作成の準備をします。

$ rosa init
I: Logged in as '${Red Hatアカウントのユーザー名}' on 'https://api.openshift.com'
I: Validating AWS credentials...
I: AWS credentials are valid!
I: Validating SCP policies...
I: AWS SCP policies ok
I: Validating AWS quota...
I: AWS quota ok
I: Ensuring cluster administrator user 'osdCcsAdmin'...
I: Admin user 'osdCcsAdmin' already exists!
I: Validating SCP policies for 'osdCcsAdmin'...
I: AWS SCP policies ok
I: Validating cluster creation...
I: Cluster creation valid
I: Verifying whether OpenShift command-line tool is available...
I: Current OpenShift Client Version: 4.7.3

ログインが完了したら、いよいよOpenShiftクラスターを作成します。AWS公式ブログの記載の通り、クラスターの作成には30〜40分程度かかるようです。

$ rosa create cluster --cluster-name=newsblogcluster
I: Creating cluster 'newsblogcluster'
I: To view a list of clusters and their status, run 'rosa list clusters'
I: Cluster 'newsblogcluster' has been created.
I: Once the cluster is installed you will need to add an Identity Provider before you can login into the cluster. See 'rosa create idp --help' for more information.
I: To determine when your cluster is Ready, run 'rosa describe cluster -c newsblogcluster'.
I: To watch your cluster installation logs, run 'rosa logs install -c newsblogcluster --watch'.
Name:                       newsblogcluster
ID:                         XXXXXXXXXXXXXXXXXXXX
External ID:                
OpenShift Version:          
Channel Group:              stable
DNS:                        newsblogcluster.phnh.p1.openshiftapps.com
AWS Account:                123456789012
API URL:                    
Console URL:                
Region:                     ap-northeast-1
Multi-AZ:                   false
Nodes:
 - Master:                  3
 - Infra:                   2
 - Compute:                 2 (m5.xlarge)
Network:
 - Service CIDR:            172.30.0.0/16
 - Machine CIDR:            10.0.0.0/16
 - Pod CIDR:                10.128.0.0/14
 - Host Prefix:             /23
State:                      pending (Preparing account)
Private:                    No
Created:                    Mar 25 2021 07:20:16 UTC
Details Page:               https://cloud.redhat.com/openshift/details/XXXXXXXXXXXXXXXXXXXX

コマンド実行後、出力されているようにrosa describe clusterやrosa logs installコマンドで作成中の状況を確認できます。また、"Details Page"のURLからOpenShiftのコンソール画面にアクセスできるので、そこから確認することもできます。

OpenShiftクラスター詳細画面

インフラリソースとしてAWSを利用していることが確認できます。

作成されるAWSリソース

では、rosa create clusterコマンドによって実際にAWS環境で作成されるリソースを確認してみましょう。

ネットワーク系のリソース

まず、VPCやサブネットといったネットワーク系のリソースが作成されます。サブネットは、パブリックのものとプライベートのものが作成され、インターネットゲートウェイやNATゲートウェイも作成されます。

また、少し細かいですが、ルートテーブルにはS3のVPCエンドポイントを指すプレフィックスリストが追加されています。

EC2インスタンス

OpenShiftを構成するノードとして、EC2インスタンスが作成されます。具体的には マスター/ワーカー/インフラストラクチャー、およびブートストラップの役割を担うインスタンスが作成されます。デフォルトのインスタンスタイプや台数は下記のようになっています。

  • マスターノード: m5.xlarge 3台
    • コントロールプレーンの役割を担うノード
  • ワーカーノード: m5.xlarge 台
    • アプリケーションのコンテナが実際に稼働するノード
  • インフラストラクチャーノード: r5.xlarge 2台

クラスター作成時のみブートストラップ用のインスタンスが起動します。これは、クラスターの初期設定にのみ使用され、作成が完了すると自動的に終了します。デフォルトでは m5.large のインスタンスタイプで1台起動します。

なお、インスタンスのAMIは、AWSマーケットプレイスを通じてRed Hatから提供されています。マスターノードとその他のノードでは異なるAMIが使用されるようです。

IAMロール

ROSAによって作成されるEC2インスタンスにはインスタンスプロファイルがアタッチされています。元となるIAMロールもROSAによって作成されるようです。

具体的には、マスターノード用のIAMロールと、インフラストラクチャーおよびワーカーノード用のIAMロールの2つが作成されます。それぞれのポリシーは下記のように定義されています。

  • マスターノード用のIAMロールのポリシー
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ec2:AttachVolume",
                "ec2:AuthorizeSecurityGroupIngress",
                "ec2:CreateSecurityGroup",
                "ec2:CreateTags",
                "ec2:CreateVolume",
                "ec2:DeleteSecurityGroup",
                "ec2:DeleteVolume",
                "ec2:Describe*",
                "ec2:DetachVolume",
                "ec2:ModifyInstanceAttribute",
                "ec2:ModifyVolume",
                "ec2:RevokeSecurityGroupIngress",
                "elasticloadbalancing:AddTags",
                "elasticloadbalancing:AttachLoadBalancerToSubnets",
                "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
                "elasticloadbalancing:CreateListener",
                "elasticloadbalancing:CreateLoadBalancer",
                "elasticloadbalancing:CreateLoadBalancerPolicy",
                "elasticloadbalancing:CreateLoadBalancerListeners",
                "elasticloadbalancing:CreateTargetGroup",
                "elasticloadbalancing:ConfigureHealthCheck",
                "elasticloadbalancing:DeleteListener",
                "elasticloadbalancing:DeleteLoadBalancer",
                "elasticloadbalancing:DeleteLoadBalancerListeners",
                "elasticloadbalancing:DeleteTargetGroup",
                "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
                "elasticloadbalancing:DeregisterTargets",
                "elasticloadbalancing:Describe*",
                "elasticloadbalancing:DetachLoadBalancerFromSubnets",
                "elasticloadbalancing:ModifyListener",
                "elasticloadbalancing:ModifyLoadBalancerAttributes",
                "elasticloadbalancing:ModifyTargetGroup",
                "elasticloadbalancing:ModifyTargetGroupAttributes",
                "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
                "elasticloadbalancing:RegisterTargets",
                "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
                "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
                "kms:DescribeKey"
            ],
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}
  • インフラストラクチャーおよびワーカーノード用のIAMロールのポリシー
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "ec2:DescribeRegions"
            ],
            "Resource": "*"
        }
    ]
}

それぞれのノードでどういったリソースを利用するのかが表されていますね。

クラスターの削除

ROSAで作成したクラスターはrosa delete clusterコマンドで削除できます。ちなみに、クラスターの削除は10分程度で完了しました。

$ rosa delete cluster --cluster=newsblogcluster
? Are you sure you want to delete cluster newsblogcluster? Yes

I: Cluster 'newsblogcluster' will start uninstalling now
I: To watch your cluster uninstallation logs, run 'rosa logs uninstall -c newsblogcluster --watch'

OpenShiftの構築や移行が簡易化できそう

ROSAの登場により、例えばオンプレ環境ですでに稼働中のOpenShiftクラスターをAWS環境に移行したい、といったニーズに対して、従来よりも簡単なアプローチが提案できそうです。

もちろん、オンプレOpenShiftからAmazon EKSに移行するのも従来通り有効です。選択肢が増えることによって、個別にケースによりマッチした解決方法を提案することができると良いですね。

以上、コンサル部のtobachi（@toda_kk）でした。

Share this article

facebook logohatena logotwitter logo

関連記事

IAM ポリシー Billing と AWSBillingReadOnlyAccess の違い

IAM ポリシー Billing と AWSBillingReadOnlyAccess の違い

User avatar
中村祐太郎
2024.12.23
Amazon Connectで自動ヒアリングした内容をBedrockで要約し、メール通知する（Kinesis Data Stream + Step Functions）

Amazon Connectで自動ヒアリングした内容をBedrockで要約し、メール通知する（Kinesis Data Stream + Step Functions）

User avatar
平井裕二
2024.12.23
[レポート]Amazon Redshiftで生成AIのためのデータ戦略を構築 #AWSreInvent

[レポート]Amazon Redshiftで生成AIのためのデータ戦略を構築 #AWSreInvent

User avatar
渡部晃季
2024.12.23
Amazon S3 Tables と Iceberg Tables on Amazon S3 のパフォーマンス比較 #AWSreInvent

Amazon S3 Tables と Iceberg Tables on Amazon S3 のパフォーマンス比較 #AWSreInvent

User avatar
石川覚
2024.12.22
Classmethod's white logo
Facebook's logo
X's logo
YouTube's logo

© Classmethod, Inc. All rights reserved.